===============OBJECT===============
An object is a set.
A set is also a subset of itself.
A set can contain another set, but the contained set would also be a proper 
subset of the containing set.
A proper subset contains some, but not all, members of a set.
A set is not a proper subset of itself.
A set can be partitioned into proper subsets.
The set partitioning is notated in OOA as the supertype relationship.
A supertype can represent a multi-way partitioning.
Each subtype is a proper subset.
An instance belongs to only one subset.
An instance can belong to an intersection of multiple sets.
The intersection is composed of a proper subset that is shared by more than 
one set.
Identifers for intersecting sets must be the same for both sets, albeit 
you could have other identifiers that are distinct.
e.g., the intersection of employees and homeowners. The instances of person are
identified (I1) by name or SS#; employees could also have another identifier of 
employee# and company (I2), and homeowners could have another identifier of name
and address (I2).
A subset is a singular proper, an intersection proper or an improper subset.
An object is a type; a named object is a variable; an instance is a value.
   Consider: object Person and instance Fred.
      The type, Object, constrains how Person is formed and what operators are 
      valid for Person.
      The variable, Person, is modifiable by the addition and deletion of 
      instances.
      The value Fred has modifiable attributes, but is always the same 
      instance. Even if Fred becomes Fredwina and the has_penis attribute 
      changes from true to false, the instance remains the same.

Where do attributes exist?
   - the object: attributes apply to whole set.
   - the supertype: attributes apply to all subsets within partition, and are 
     in addition to object-level attributes.
   - the subtype: attributes apply only to members of the proper subset, and 
     are in addition to object-level and supertype-level attributes.
Attributes are defined by subset membership, which is defined by object plus 
enclosing supertype(s).
Only proper subsets can be enclosed by supertypes.

Datatypes need to be objects in model?

Make sure object subsystem tests test for supertype as subtype of itself 
(diamond) and supertype can't intersect itself. TODO: contrast with third
manifesto. Diamond violates set theory (a set can't intersect itself), but IIRC,
third manifesto used rhombus example in diamond pattern.

TODO: If referential attributes are non-referential attributes of another 
object, should they be constrained to be the same attribute as a 
non-referential attribute?

===============DOMAIN===============
Bridge needs to be related to parameters in some manner.

Bridge data (parameters) is: unordered, typed via definer, uses descriptive 
   naming (best practice, not enforcable, not to be modeled)

miUML spanning concept doesn't belong in metamodel, as it's about how domain
   elements can span subsystems. As the subsystem is just a nicety for managing 
   the view of the domain model, spanning is a tool concern, not a modeling
   concern.

miUML Domain Build Specification is an architecture domain concern and also 
   doesn't belong in the metamodel.

miUML Subsystem Range is also a tool concern for managing the view of the 
   model.

miUML Element is captured by domain to object and domain to type relationships.

================TYPE================
Executable UML defines: boolean, string, integer, real, date, timestamp,
   arbitrary_id, numeric, enumerated, composite, instance reference, and event 
   reference.

Instance reference and event reference are references specific to an object
   declaration. Generic types must be abstracted to define a generic set of
   operators.

OOA data paper defines: enumerated, boolean, extended boolean, symbolic, 
   numeric, ordinal, time, duration, and arbitrary.

Range of data: Does it make sense in the metamodel, or should it be treated like
   multiplicity of relationship ends?
   - Core types tend to have infinite ranges. It should be left to the
     implementation to bound these.
   - User data types could be range limited versions of core types. The
     conditional 'could' shows that range limits can't be attributes of UDT.

No need for real and integer, if numeric.

Extended boolean is bad idea. If your boolean relationship is uncomparable, then
you're doing it wrong. i.e., the test shouldn't be boolean.

Can a domain type use a composite type for it's base? Probably allowable, but 
   what's the point? You wouldn't be able to constrain it further. Are there 
   any other core types this would apply to?

On ordinal, do we need to add other operations like insert (before, after) and 
   remove? YES

Do enumerations need a default more so than other data types?

A Core type has a name ("enum", "numeric", "symbolic"), a list of supported 
   operations, and constraints on operation usage. e.g., "not" is only used 
   with one value, whereas "and" requires two values.

A Core Type Instance has a variable name, value assignment, and participates in 
   operations.

Type creation will have dependencies on other types, due to possible other type
result outcomes from operations. Boolean must definitely exist first. (others?)

Enumeration values are explicitly called out, unlike other types, where the
values are "known" according to the type. e.g., boolean {true, false}

All actions require operators. i.e., "execute" could run event and operation
actions.

All types require values. You can remove a value, but not a type (even though a
path exists right now). e.g., an instance is a value, which is of an object
type.

Ordinal requires value to be subtyped as Indexable and non-indexable to
constrain which types of values can be part of an ordinal.

A type defines a set of values.

An empty set value exists for all types.

++++++++VARIABLES and VALUES+++++++++++
See "Fred" discussion in OBJECT section.

Operators are defined for a Type, but do not operate on Type.
Type modifier operators create new values of another type.
Variables are typed.
Variables hold values of the same type.
Values aren't modifiable.
Variables are modifiable.
Left-hand, assignment operands must be variables.

Values in metamodel
- Parameter (from process model perspective)
- Operand (except LH in assignment)
- Return Value
- Referential Attribute
- Instance

Variables in metamodel
- Transient Data (OL:MWS term for a local variable in a process model)
- LH Operand (in assignment)
- Non-referential Attribute
- Parameter
- Named Object (Fred discussion)

NOTE: Crossover with Reference Element

==============STATES===============
OOA96 states that an instance created by a non-creation event doesn't execute
   the action of the state it was created in.

State - contains state action
State Action - must use event data
Event Data - parameter set composed from any data type known to the domain being
modeled.
Event - is composed of number, name, and event data(from transition rule).
Transition (Rule) - destination state, event data, event.

A creation state is the designated default state of an object's state model. An
object state model can be a lifecycle or assigner state model.

A creation state involves no entry transition rule.

A creation event creates an instance of the object at the beginning of the
transition rule processing. The event handling follows normal event rules.
This means that a creation event transition occurs asynchronously.

A creation event can only be associated with lifecycle state models.

A deletion state deletes the instance after state action processing.

A deletion state must not leave the model in an invalid configuration.

A deletion state can only be associated with lifecycle state models.

A state model has 1 creation state, 0..1 deletion state(lifecycle only), and
1..* living state.

The same data rule implies that the state entered via a creation transition,
can't be entered from a state-to-state transition, because of the (implicit)
instance identifier associated with a state-to-state event. OL:MWS and OOA96
allow a transition to a creation state to carry an identifier, so only entry
via a creation transition forbids other entry. (NOTE: This means that the FAQ
in OOA96 is wrong concerning re-entry into creation states, as it doesn't
imply a distinction between the two types of entry.)

Need to make distinction between state model and state machine. Each instance
will have a state machine. 

A lifecycle model is associated with an object, so it is either a segment or a 
whole. The state machine collects the segments, which means the lifecycle model
isn't specialized.

============PROCESS============
OL:MWS 6.4 Reuse of Processes "it is common to find the same process used in 
several [process models]" "When a process is reused in this manner, it should 
be labeled with the same process identifier and name wherever it appears"

NOTE: There is a distinction between process and process model.

Processes in OL:MWS are assigned to objects, so processes are object methods.

===========INSTANCES===========
Instances as used in the process models aren't physical instances as produced in
the runtime output. This means that deletions of instances in the metamodel are
targeted at removing model elements, not physical instances. Physical instance
removal isn't done via the normal action language keyword (e.g., OAL "delete")
or a deletion state in a lifecycle model.

Physical instance creation and deletion is wholly governed by the Architecture 
domain. This means that object instances can be maintained as a pre-initialized
pool at start, a dynamic pool, or a combination of both.

It is also assumed that physical transient variable deletion occurs at the exit
from the process model (if desired by the model compiler).

Instances in process models might have names that are relative only to the
process model.

Accessor instances in process models will use the same name as the Accessor
class. e.g., 
   type accessor(type param); // object definition
   a = accessor(value);       // accessor instance usage
   b = accessor(value);       // accessor instance usage
   In a sequential processing, a and b could be accessing the same accessor
   instance, but in a parallel processing, a and b would have to be accessing
   different instances of the accessor.

Object instances (for example) would have unique names only within process 
model scope. e.g.,
   PROCESS MODEL A
      a = OBJ_A; an instance of OBJ_A is assigned to a variable named, a.
      b = OBJ_A; a different instance of OBJ_A is assigned to a variable 
                 named, b.
   PROCESS MODEL B
      a = OBJ_A; an instance of OBJ_A is assigned to a variable named, a.
      b = OBJ_A; a different instance of OBJ_A is assigned to a variable 
                 named, b.
      Neither the variables or the instances assigned are the same as in PROCESS
      MODEL A.

=== TODO ===
Add idea of range for types.
Explore 3RD MANIFESTO relational algebra for instance operations. Simplifies by
removal of redundant operators.

